For some computer programs, it is critical that steps in the program are performed within defined time periods, or at defined times. Examples of such programs are control programs for operating mobile telephones. Typically, the program must respond to external events or changes of state in a consistent way, at or within a certain time after the event. This is referred to as operating in “real time”.
For many other programs, however, the time taken to execute the program is not critical. This applies to most common computer programs, including spreadsheet program and word processing programs. On the other hand, whilst the exact time taken by such programs is not critical, in most cases, users would prefer quicker execution where this is possible.
Applications programs interact with the computers on which they run through operating systems. By using the applications programming interface (API) of the operating system, the applications program can be written in a portable fashion, so that it can execute on different computers with different hardware resources. Additionally, common operating systems such as Linux or Windows provide multi-tasking; in other words, they allow several programs to operate concurrently. To do so, they provide scheduling; in other words, they share the usage of the resources of the computer between the different programs, allocating time to each in accordance with a scheduling algorithm. Operating systems of this kind are very widely used, but they generally make no provision for running real time applications, and they therefore are unsuitable for many control or communications tasks.
For such tasks, therefore, real time operating systems have been developed; one example is ChorusOS (also know as Chorus) and its derivatives.
These operating systems could also be used to run other types of programs. However, users understandably wish to be able to run the vast number of “legacy” programs which are written for general purpose operating systems such as Windows or Linux, without having to rewrite them to run on a real time operating system.
To address this need, the applicant has developed a method for running multiple operating systems simultaneously, even when the operating systems are designed for different purposes. A detailed description of this method is provided in WO2004/090719 which is incorporated herein by reference.
In particular, the method allows for one of the operating systems (for example, a real time operating system) to perform without disturbance, and the other (for example, a general purpose operating system) to perform as well as possible using the remaining resources of the computer. That is, the multiple operating systems are slightly modified and provided with a common program which schedules between them, in which one of the operating systems (the “primary” or “critical” operating system) is favoured over another (the “secondary” or non-critical operating system). The method allocates hardware preferentially to the critical operating system, and it denies the secondary operating system or systems access which would interfere with that of the critical operating system. The secondary operating systems are modified so that they cannot mask interrupts, and their interrupt service routines are modified to make them responsive to messages indicating that an interrupt occurred. The common program handles all hardware exceptions by passing them to the interrupt service routines of the primary operating system, and where a hardware interrupt was intended for one of the secondary operating systems, an interrupt message or notification is generated. Next time that secondary operating system is scheduled by the common program, the message or notification is passed to it, and the common program calls its interrupt service routine to service the interrupt. This is referred to as “virtual” interrupts.
Thus, the secondary operating systems cannot pre-empt the primary operating system (or, in general, a higher importance secondary operating system) in any way on occurrence of an interrupt, since all are initially handled by the primary operating system and only notified to the secondary operating system for which they are destined after the primary operating system has finished execution and that secondary operating system is scheduled.
Handling of such interrupts is thus deferred until no critical task in the primary operating system is occurring. When they are eventually actioned, however, the routines of the secondary operating system may operate substantially unmodified fashion so that the behaviour is (except for the delay) as expected by the secondary operating system.
In the above described method, tasks of the primary operating system are always performed prior to concurrent tasks of the second operating system. However, different tasks may have different priorities. For example, a task of the primary operating system may be less important than a task of the secondary operating system. This may result in undesired latencies in respect of (some) tasks of the secondary operating systems.
One way to deal with this problem would be to provide a task scheduler for scheduling the order of tasks in both (all) operating systems. However, this would be complicated and inefficient.
It is an object of the present invention to address these problems. In particular, it is an object of the present invention to improve the efficiency of performing tasks of the secondary operating system(s). More particularly, it is an object of the present invention to reduce the (interrupt) latency in respect of tasks of the secondary operating systems. Furthermore, it is an object of the invention to achieve this without employing a dedicated task scheduler.